تحلیل فنی بهره‌برداری از آسیب‌پذیری Race Condition با استفاده از Turbo Intruder
سوءاستفاده از Race Condition با استفاده از Turbo Intruder یکی از تکنیک‌های مهم در حوزه امنیت برنامه‌های وب است. Race Condition زمانی رخ می‌دهد که چندین Thread یا Process به‌صورت هم‌زمان به منابع مشترک دسترسی پیدا کنند و این هم‌زمانی می‌تواند منجر به رفتارهای غیرقابل پیش‌بینی در برنامه شود. در این مقاله، نحوه بهره‌برداری از این آسیب‌پذیری را با استفاده از افزونه Turbo Intruder در Burp Suite به‌صورت عملی بررسی می‌کنیم.
فهرست مطالب
- ویژگی‌های کلیدی
- تست بر روی یک برنامه آسیب‌پذیر
- رفتار مورد انتظار برنامه
- رفتار ناخواسته برنامه
- درباره آسیب‌پذیری
- نتیجه‌گیری
ویژگی‌های کلیدی
در ادامه، برخی از ویژگی‌های کلیدی مرتبط با Race Condition آورده شده است:
- دسترسی هم‌زمان (Concurrent Access): Race Condition زمانی رخ می‌دهد که چندین Process یا Thread به‌طور هم‌زمان به منابع مشترک در یک برنامه وب دسترسی پیدا می‌کنند. این منابع مشترک می‌توانند شامل رکوردهای پایگاه داده، فایل‌ها یا متغیرهایی باشند که در حافظه نگهداری می‌شوند؛ همچنین سایر مؤلفه‌های حیاتی برنامه را نیز در بر می‌گیرند.
- رفتار غیرقابل پیش‌بینی (Unpredictable Behaviour): به‌دلیل ماهیت غیرهم‌زمان (Asynchronous) و موازی (Parallel) برنامه‌های تحت وب، زمان‌بندی و ترتیب اجرای عملیات هم‌زمان ممکن است متفاوت باشد. در نتیجه، این شرایط می‌تواند منجر به رفتارهای غیرقابل پیش‌بینی شود؛ به‌گونه‌ای که نتیجه یک عملیات تحت تأثیر عواملی مانند زمان ارسال درخواست، بار پردازشی سیستم یا تأخیر شبکه قرار گیرد.
آزمایش بر روی یک برنامه آسیب‌پذیر
برای نمایش عملی Race Condition، از یک برنامه آسیب‌پذیر استفاده خواهیم کرد. ابتدا منطق مورد انتظار برنامه را بدون استفاده از درخواست‌های هم‌زمان اجرا می‌کنیم تا رفتار عادی آن را مشاهده نماییم. سپس، با ارسال چندین درخواست هم‌زمان، تلاش خواهیم کرد تا به رفتار ناخواسته و آسیب‌پذیر دست یابیم.
نسخه آسیب‌پذیر این برنامه را می‌توانید از لینک زیر دریافت نمایید:
https://github.com/projectdiscovery/php-app-race-condition
رفتار مورد انتظار برنامه
منطق مورد انتظار این برنامه آن است که کاربر بتواند مبلغی را از حساب خود برداشت کند و موجودی باقی‌مانده پس از هر برداشت به کاربر نمایش داده شود. در ابتدا، موجودی کل حساب برابر با ۱۰٬۰۰۰ دلار است.
بر اساس منطق برنامه، اگر یک کاربر مبلغ ۱۰ دلار را به تعداد ۸۰ مرتبه برداشت کند، موجودی باقی‌مانده در حساب باید برابر باشد با:
$۱۰,۰۰۰ – (۱۰ × ۸۰) = $۹,۲۰۰
این روند را می‌توان از طریق خروجی ابزار Burp Intruder نیز مشاهده کرد؛ به این صورت که تعداد درخواست‌های هم‌زمان (concurrent requests) بر روی مقدار ۱ تنظیم شده و عملیات برداشت به تعداد ۸۰ بار انجام می‌شود. در این حالت، برنامه مطابق منطق صحیح خود عمل خواهد کرد و موجودی حساب به‌درستی کاهش خواهد یافت.
رفتار ناخواسته برنامه
رفتار ناخواسته برنامه زمانی آشکار می‌شود که کاربران چندین درخواست هم‌زمان را با استفاده از افزونه Turbo Intruder ارسال می‌کنند. این افزونه را می‌توان از طریق BApp Store در محیط Burp Suite دریافت و نصب کرد.
پس از نصب افزونه، می‌توان درخواست هدف را به افزونه Turbo Intruder ارسال (Forward) کرده و از آن برای انجام تست‌های هم‌زمان و بهره‌برداری از آسیب‌پذیری استفاده نمود.
در محیط Turbo Intruder از اسکریپت پیش‌فرض race-single-packet-attack.py استفاده می‌کنیم؛ با این حال، پیکربندی آن را متناسب با نیاز خود تغییر می‌دهیم. مشابه مرحله قبل، عملیات برداشت مبلغ ۱۰ دلار را به تعداد ۸۰ بار انجام می‌دهیم، اما این بار تعداد درخواست‌های هم‌زمان (concurrent requests) را روی مقدار ۱۵ تنظیم می‌کنیم و موتور اجرا را برابر با Engine.BURP قرار می‌دهیم.
پس از تکمیل پیکربندی، بر روی گزینه Attack کلیک کنید تا حمله آغاز شود. با بررسی نتایج مشاهده خواهید کرد که پس از ارسال ۸۰ درخواست، موجودی باقی‌مانده در حساب ۹۶۰۰ دلار است که بیشتر از مقدار مورد انتظار (۹۲۰۰ دلار) می‌باشد.
درباره آسیب‌پذیری
آسیب‌پذیری Race Condition زمانی رخ می‌دهد که چندین Thread یا Process به‌طور هم‌زمان به منابع مشترک دسترسی پیدا کنند و برنامه فاقد مکانیزم مناسب برای مدیریت این هم‌زمانی باشد. در این شرایط، ترتیب اجرای عملیات می‌تواند منجر به وضعیت‌های غیرمنتظره و ناایمن شود.
در سناریوی ارائه‌شده، برنامه به‌درستی بررسی نمی‌کند که آیا عملیات برداشت در هر لحظه با موجودی حساب هماهنگ است یا خیر. با ارسال درخواست‌های هم‌زمان، بررسی و به‌روزرسانی موجودی به‌درستی انجام نمی‌شود و این موضوع باعث می‌شود که کاربر بتواند بیشتر از حد مجاز برداشت کند، بدون اینکه سیستم مانع آن شود. این نقص در کنترل هم‌زمانی، یک نمونه کلاسیک از Race Condition در برنامه‌های وب است.
در نگاه اول، ممکن است این‌گونه به نظر برسد که یک برنامه تحت وب توسعه‌یافته با زبان PHP — زبانی که به‌صورت پیش‌فرض از Multi-threading پشتیبانی نمی‌کند — نمی‌تواند در معرض حملات Race Condition قرار گیرد. با این حال، این نوع حملات به‌طور واقعی در چنین محیط‌هایی نیز امکان‌پذیر هستند.
دلیل این امر آن است که وب‌سرورهایی مانند Apache، درخواست‌ها را به‌صورت asynchronous مدیریت می‌کنند. در این شرایط، اگر دو درخواست تقریباً به‌طور هم‌زمان به سرور ارسال شوند، ممکن است آن‌ها به‌صورت موازی بر روی یک CPU چند هسته‌ای اجرا شده یا از طریق مکانیزم اشتراک‌گذاری زمان پردازنده (CPU time-sharing) در سطح سیستم‌عامل، با یکدیگر تداخل پیدا کنند.
در نتیجه، به‌جای آن‌که موجودی حساب پس از پردازش هر دو درخواست برابر با $۹۹۸۰ شود، موجودی به اشتباه $۹۹۹۰ باقی می‌ماند. این اختلاف به این دلیل رخ می‌دهد که سرور، درخواست دوم را زمانی پردازش می‌کند که عملیات مربوط به درخواست اول هنوز به‌طور کامل به پایان نرسیده است. اگرچه هر دو عملیات برداشت به‌درستی انجام می‌شوند و مجموعاً ۲۰ دلار باید کسر شود، تنها ۱۰ دلار از موجودی واقعی حساب کسر می‌گردد.
نتیجه‌گیری
در نهایت، Race Conditionها تهدیدی جدی برای امنیت و قابلیت اطمینان برنامه‌های تحت وب به‌شمار می‌آیند. از این‌رو، انجام تست‌های جامع و پیروی از رویکردهای برنامه‌نویسی ایمن و مقاوم برای کاهش مؤثر این آسیب‌پذیری‌ها کاملاً ضروری است.
در سناریوی ارائه‌شده، تعداد درخواست‌های هم‌زمان در ابزار Burp Intruder بر روی مقدار ۱ تنظیم شده بود؛ زیرا برنامه مورد بررسی بسیار ساده و با قابلیت‌های محدود طراحی شده است. اما در سناریوهای واقعی، بهره‌برداری از Race Condition با استفاده از افزونه Turbo Intruder می‌تواند رویکردی بسیار مؤثر و عملی باشد؛ چرا که این افزونه انعطاف‌پذیری بالایی در پیکربندی و اجرای حملات مبتنی بر شرایط رقابتی فراهم می‌کند.
